pkcs1: split der objects into *Ref and *Owned - #2411

Is UintType generic parameter name okay?

I generally use U for that sort of thing

I had to add UintLike trait in der

I'd prefer not to add additional traits in this PR, particularly ones unrelated to pkcs1 like IntLike.

Any reason it can't just be AsRef<[u8]>? I mean, it looks like we'd need to add impls, but that seems more straightforward than trying to shoehorn multiple new traits into this PR.

If we really need to add UintLike I'd prefer it be its own PR.

I guess the main problem is there's a divergence between Uint(Ref)::to_bytes and its underlying encoding due to the leading zero stripping

I think AsRef<[u8]> for Uint would be unintuitive, because of leading zeros/ones.

But I can add AsRef<[u8]> if you'd like.

No, that doesn't seem like a good solution either.

One thing that's annoying is UintRef didn't get the same treatment as e.g. OctetStringRef in that it still has a lifetime, which makes writing other bounds annoying (e.g AsRef<UintRef> would be nice here).

So I guess we can do UintLike for now, with a TODO to eventually get rid of it and replace it with AsRef<UintRef>. I'd probably prefer it actually exposed the full UintRef rather than just its bytes, and be added in its own separate PR first.

Edit: I misunderstood you wanted

fn as_uint_ref<'a>(&'a self) -> &UintRef<'a>;

Should I:

• remove the .len() and .is_empty() from UintRef,
• or leave it in both UintRef and UintLike trait?

I think UintLike should just be a helper to retrieve a UintRef which can be replaced by AsRef<UintRef> in the future when we can make a breaking change from &UintRef<'a> to &'a UintRef.

I don't think there should be a need to add/remove any other methods.